The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Some of features of internetworking devices that are deployed into production may be purposefully disabled. Such features may include non-critical and optional features that may useful only in certain situations. For example, a feature allowing monitoring data packets received from a particular node may not need to be enabled all the time. However, it may be beneficial to enable the monitoring feature when the particular node is malfunctioning. In such a situation, the monitoring feature may be activated and remain enabled until a network administrator completes troubleshooting the particular device.
One reason for non-critical features to remain temporarily disabled in a deployed network is to ensure the stability and reliability of the network. For example, in a standard configuration of a router in a deployed network, optional features of the router may be disabled to make the router's resources fully available to router's primary functions, such as routing data packets. Since the primary functions and optional features of the router often consume the same router's resources, such as CPU and memory, the standard instrumentation of the router often gives preferential treatment to the primary functions of the router and less favorable treatment to the router's optional features.
Enabling and disabling features in a deployed network is often a part of technical support activities and often involves reconfiguring devices in the network. However, since reconfiguring of a production network by a network administrator/technician may be prone to human error, and a defective reconfiguration of the production network may negatively impact the operation capabilities of the whole network, reconfiguration may be closely supervised. For example, a proposal of changes to the configuration may need to be reviewed and approved by a supervisor before the reconfiguration can be implemented. To ensure the correctness of the proposed changes, the approval process is often complex and time consuming, and thus it may take a long time to complete.
Consequently, for example, upon receiving a service call indicating a network's problem, a network administrator may need to draft and submit a proposal of the network modifications, and may run out of the time allotted to the service call before the proposal is actually approved.